Method and apparatus of configuring a data broadcast service

ABSTRACT

Disclosed are an apparatus and method of broadcasting a message to one or more servers operating in one or more domains. One example method of operation may include creating a message to be broadcasted via user input provided by a user of a computer interface. The method may also include serializing the message to a predetermined format and transmitting the message to an application programming interface (API). The method may also provide scheduling a broadcast of the message based on the user input, and transmitting the message to the at least one server responsive to the scheduled broadcast.

TECHNICAL FIELD OF THE INVENTION

This invention relates to a method and apparatus of configuring a databroadcast service application, and in particular, to autonomouslycreating a scheduled broadcast based on user input preferences.

BACKGROUND OF THE INVENTION

User workstations or subscriber devices, personal computers (PCs),handheld devices, tablet devices, smart phone devices, and other webcapable devices operate in a communication network by communicating withcontrolling devices, servers and access points. In order for the webcapable device to receive messages from another device operating in thecommunication network it needs to subscribe to a broadcasting channel ofcommunication. The subscription process may include, for example, one ormore hyper text transfer protocol (HTTP) POST requests. For instance,one POST request may be for a subscription and another POST request maybe to acknowledge the subscription.

A POST request is used to send data to be processed to a server, whichmay be performed by a common gateway interface (CGI) script. A POSTrequest may include a block of data sent with the request in the messagebody. A POST request may also include extra headers to describe themessage body, such as content-type and content-length. The HTTP responseis normally program output and is not a static file. POST can be used torequest various different data types.

“POST” is one of many request methods supported by the hypertexttransfer protocol (HTTP) used by Internet users of the world wide web.The POST request may be used when the client needs to send data to theserver as part of the request, for example, when uploading a file orsubmitting a completed form to a server. In contrast to the more general“get me this resource” (GET) request method, where only a URL andheaders are sent to the server, POST requests also include a messagebody. This allows for arbitrary data length of any type to be sent tothe server. For instance, headers used in a POST request may indicatethe message body's Internet media type to the server.

In general, POST requests are used to transfer data from a client to aweb server since the web server does not log the sent data. This permitsbinary data to be sent, which is useful for transferring byte arrays orserialized Java objects, such as JavaScript object notation message(JSON) format. POST provides the portability of the request to anyserver platform. This allows for any web capable server to be asubscriber of the broadcast service without any extra configuration orsoftware, additionally it allows the system to be programming languageagnostic because most web languages are capable of consuming POSTrequests.

Users of web enabled devices may desire to perform administrativefunctions with minimal input. For example, backend applications, such asgeneral purpose servers, e-mail servers, calendar servers and othercommunication servers may require substantive administrator experienceto configure and execute user commands. Currently, there are variousdifferent communication methods implemented between servers whichutilize a subscription/subscriber pattern, however, these methodsrequire a live remote connection between servers by utilizing a TCP orUDP-based connection.

SUMMARY OF THE INVENTION

One embodiment of the present invention may include a method ofbroadcasting a message to at least one server, the method may includecreating a message to be broadcasted via user input, serializing themessage to a predetermined format, transmitting the message to anapplication programming interface (API), scheduling a broadcast of themessage based on the user input, and transmitting the message to the atleast one server responsive to the scheduled broadcast.

Another example embodiment of the present invention may include anapparatus configured to broadcast a message to at least one server. Theapparatus may include a user interface configured to receive user inputto create a message to be broadcasted. The apparatus may also include aprocessor configured to serialize the message to a predetermined format,and a transmitter configured to transmit the message to an applicationprogramming interface (API). The processor is further configured toschedule a broadcast of the message based on the user input, and thetransmitter is further configured to transmit the message to the atleast one server responsive to the scheduled broadcast.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates example network configurations, according to exampleembodiments of the present invention.

FIG. 2 illustrates a flow diagram of an example method according to anexample embodiment of the present invention.

FIG. 3 illustrates an example network entity device configured to storeinstructions, software, and corresponding hardware for executing thesame, according to example embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

It will be readily understood that the components of the presentinvention, as generally described and illustrated in the figures herein,may be arranged and designed in a wide variety of differentconfigurations. Thus, the following detailed description of theembodiments of a method, apparatus, and system, as represented in theattached figures, is not intended to limit the scope of the invention asclaimed, but is merely representative of selected embodiments of theinvention.

The features, structures, or characteristics of the invention describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “exampleembodiments”, “some embodiments”, or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment of the present invention.Thus, appearances of the phrases “example embodiments”, “in someembodiments”, “in other embodiments”, or other similar language,throughout this specification do not necessarily all refer to the samegroup of embodiments, and the described features, structures, orcharacteristics may be combined in any suitable manner in one or moreembodiments.

In addition, while the term “message” has been used in the descriptionof embodiments of the present invention, the invention may be applied tomany types of network data, such as, packet, frame, datagram, etc. Forpurposes of this invention, the term “message” also includes packet,frame, datagram, and any equivalents thereof. Furthermore, while certaintypes of messages and signaling are depicted in exemplary embodiments ofthe invention, the invention is not limited to a certain type ofmessage, and the invention is not limited to a certain type ofsignaling.

FIG. 1 illustrates a communication network according to exampleembodiments of the present invention. Referring to FIG. 1, a broadcastserver 102 provides an interface for a user to input a message. Themessage may be a calendar entry corresponding to a calendar application104 installed on the broadcast server 102. The message may include arange of times for the message to be broadcasted (e.g., every day, everytwo days, once a week, etc.). The message is transferred to a schedulerengine 106 that is in communication with a notification service 108.Subscribers 110, 120 and 130 may be part of different domains 112, 122and 132, respectively. The subscribers 110-130 may receive the calendarmessage(s) from the NS 108 depending on their status and subscriptioninformation.

As stated above, the broadcast server 102 provides an interface for auser to input or create a message with a range of dates for this messageto be broadcasted. For example, the range of dates may be amultiple-layered calendar request to be performed by the calendarapplication 104 at the specified times. The actual message could beanything that is required for a successful communication to beestablished. For instance, in the case of scheduling a date for aspecific task to be performed, the transferred message will include atleast one date. The message contents and format are based on theapplication. In this example, the message will need at least one date,allowing the subscriber(s) to know when the contents of the messageshould be executed and/or scheduled.

An example message is composed of a text subject included in the messagebody. The text subject may include a date and the body of the messagemay include other information that is being broadcasted. The messagebody could be simple text or an object. This message is serialized toJSON including a target host URL. An example of serializing a datamessage into JSON may include: {“subject” : “11-12-2011 09:30:30”,“body”: {“subject”: “maintenance”, “body”: “The server is undergoingmaintenance”}}. This example is based on a scheduled server maintenancedate that includes a numeric date, time and description of the serviceto be performed.

According to example embodiments of the present invention, cross-domainmessage broadcasting (e.g., domains 112, 122 and/or domain 132) via HTTPPOST requests may be performed without a “live” or “open” communicationbetween web servers. A user may schedule tasks to multiple web serversthat reside in heterogeneous domains by implementing HTTP POST requests.One example may include the scheduling of a maintenance period formultiple web servers. Since the subscribed web servers do not require anactive connection be setup between the various web servers, the channelmaintenance overhead for communication between the web server sender andweb server receiver may be reduced or eliminated.

The message may be sent to a calendar application, such as Google®Calendar via the Google calendar REST API. REST-styled architecturesinclude clients and servers. Clients initiate requests to servers, whileservers process requests and return appropriate responses. Requests andresponses are built around the transfer of representations of resources.A resource can be essentially any coherent and meaningful concept thatmay be addressed. A representation of a resource is typically a documentthat captures the current or intended state of a resource.

At any particular time, a client can either be in transition betweenapplication states or “at rest.” A client in a rest state is able tointeract with its user, but creates no load and consumes no per-clientstorage on the servers or on the network. The client begins sendingrequests when it is ready to make the transition to a new state. Whileone or more requests are outstanding, the client is considered to be intransition. The representation of each application state contains linksthat may be used next time the client chooses to initiate a new statetransition. RESTful applications maximize the use of the pre-existing,well-defined interface and other built-in capabilities provided by thechosen network protocol, and minimize the addition of newapplication-specific features on top of it.

In operation, the message generated by the user includes informationthat could be used to schedule an operation for the subscribed servers110-130. The message will be broadcasted to those subscribed servers110-130 via the broadcast server 120. The message will be submitted tothe scheduling engine (scheduler) 106. The scheduler executes a codebased on the user's input dates to send the message to the notificationengine such as Amazon simple notification service (SNS). The code refersto the software-based program that schedules the execution of othersoftware, such as Microsoft® Message Queuing. Scheduler softwaresolutions are well-known and therefore the details of the softwareprogram scheduling operations will be omitted from further discussion.

The message is broadcasted to all subscriber web applications via a HTTPPOST message format in a domain agnostic manner. Because the message isbroadcasted to a notification engine, the sender only needs to send aPOST request to this notification engine including the message. Theengine is then capable of sending a POST request to each of itssubscribers (other servers) with the same message. Because thesubscribers can reside in different domains, the communication may bereferred to as domain agnostic.

The subscriber web application hosts a rest endpoint that receives themessage/notification. This REST endpoint includes logic to acknowledgeif a message/notification is a request for subscription or a regularmessage, and, if a request for notification is received the endpointreturns a HTTP response to confirm its subscription. The term “RESTendpoint” is used to indicate that the URL is residing in a web server.The REST endpoint is capable of understanding REST-based operations. Ifthe received message is deemed a regular message it may process themessage and either store its contents or use them for the purpose of ahosted web application.

The message used to confirm a subscription has a specific format basedon the notification engine used by the application service. Regularmessages have a different format than a subscription confirmationmessage and therefore are treated as messages sent from a broadcastserver. Referring to FIG. 1, the domains 1, 2, . . . N are symbolicrepresentations of heterogeneous web domains such as kaseya.com,google.com, msn.com, etc. The service operation messages and theircorresponding responses are encoded as JavaScript object notationmessages (JSON), which are used to represent simple data structures andassociative arrays or objects. JSON is language-independent and usesparsing which provides interoperability of different programminglanguages and their corresponding operating environments.

According to one example embodiment, a user accesses the system via auser interface. This interface allows the user to create a dated messageor event via some form of text and/or calendar input. This message isbuilt and serialized to JSON upon creation. The message or event isscheduled by a scheduling system, and is to be executed on the datespecified by the user. Once the message is triggered for execution fromwithin the scheduling system, a code will send this message to anotification engine, such as the Amazon simple notification service SNS108 via an HTTP request. This engine will then broadcast the messageusing an HTTP request to each of the subscribers' endpoint, presumablyweb servers 110, 120 and/or 130. The message arrives at the web serversor subscribers as a HTTP request and the server(s) are capable and ofde-serializing the JSON message and executing a code based on themessage. The subscribers or web servers can belong to any web domain,and the time between transmitting and processing messages, the systemhas the potential of being idle.

FIG. 2 illustrates a flow diagram illustrating an example method ofoperation according to an example embodiment of the present invention.Referring to FIG. 2, a method of broadcasting a message to at least oneserver is disclosed. The method may include creating a message to bebroadcasted via user input, at operation 202. The method may alsoinclude serializing the message to a predetermined format, at operation204, transmitting the message to an application programming interface(API), at operation 206, scheduling a broadcast of the message based onthe user input, at operation 208 and transmitting the message to the atleast one server responsive to the scheduled broadcast, at operation210.

The operations of a method or algorithm described in connection with theembodiments disclosed herein may be embodied directly in hardware, in acomputer program executed by a processor, or in a combination of thetwo. A computer program may be embodied on a computer readable medium,such as a storage medium. For example, a computer program may reside inrandom access memory (“RAM”), flash memory, read-only memory (“ROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), registers, hard disk, aremovable disk, a compact disk read-only memory (“CD-ROM”), or any otherform of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such thatthe processor may read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anapplication specific integrated circuit (“ASIC”). In the alternative,the processor and the storage medium may reside as discrete components.For example, FIG. 3 illustrates an example network element 300, whichmay represent any of the above-described network components 102, 106,108, 110, 120, 130, etc.

As illustrated in FIG. 3, a memory 310 and a processor 320 may bediscrete components of the network entity 300 that are used to executean application or set of operations. The application may be coded insoftware in a computer language understood by the processor 320, andstored in a computer readable medium, such as, the memory 310. Thecomputer readable medium may be a non-transitory computer readablemedium that includes tangible hardware components in addition tosoftware stored in memory. Furthermore, a software module 330 may beanother discrete entity that is part of the network entity 300, andwhich contains software instructions that may be executed by theprocessor 320. In addition to the above noted components of the networkentity 300, the network entity 300 may also have a transmitter andreceiver pair configured to receive and transmit communication signals(not shown).

While preferred embodiments of the present invention have beendescribed, it is to be understood that the embodiments described areillustrative only and the scope of the invention is to be defined solelyby the appended claims when considered with a full range of equivalentsand modifications (e.g., protocols, hardware devices, software platformsetc.) thereto.

1. A method of broadcasting a message to at least one server, the methodcomprising: creating a message to be broadcasted via user input;serializing the message to a predetermined format; transmitting themessage to an application programming interface (API); scheduling abroadcast of the message based on the user input; and transmitting themessage to the at least one server responsive to the scheduledbroadcast.
 2. The method of claim 1, wherein the message is a calendarmessage comprising at least one date to be broadcast and at least timeto be broadcast.
 3. The method of claim 2, wherein the serializedmessage is a JavaScript object notation message (JSON) comprising asubject portion that includes at least one date and time, and at leastone body portion that includes other message information.
 4. The methodof claim 1, further comprising: receiving a hyper text transfer protocol(HTTP) response to confirm the at least one server's subscription to thebroadcast, the HTTP response being received responsive to the broadcastmessage.
 5. The method of claim 1, wherein the message further comprisesa target uniform resource locator (URL) associated with the at least oneserver.
 6. The method of claim 1, wherein the message is broadcast to aplurality of domains via a HTTP POST message.
 7. The method of claim 1,wherein the message is broadcast to a REST endpoint device.
 8. Anapparatus configured to broadcast a message to at least one server, theapparatus comprising: a user interface configured to receive user inputto create a message to be broadcasted; a processor configured toserialize the message to a predetermined format; a transmitterconfigured to transmit the message to an application programminginterface (API); and wherein the processor is further configured toschedule a broadcast of the message based on the user input, and thetransmitter is further configured to transmit the message to the atleast one server responsive to the scheduled broadcast.
 9. The apparatusof claim 8, wherein the message is a calendar message comprising atleast one date to be broadcast and at least time to be broadcast. 10.The apparatus of claim 9, wherein the serialized message is a JavaScriptobject notation message (JSON) comprising a subject portion thatincludes at least one date and time, and at least one body portion thatincludes other message information.
 11. The apparatus of claim 8,further comprising: a receiver configured to receive a hyper texttransfer protocol (HTTP) response to confirm the at least one server'ssubscription to the broadcast, the HTTP response being receivedresponsive to the broadcast message.
 12. The apparatus of claim 8,wherein the message further comprises a target uniform resource locator(URL) associated with the at least one server.
 13. The apparatus ofclaim 8, wherein the message is broadcast to a plurality of domains viaa HTTP POST message.
 14. The apparatus of claim 8, wherein the messageis broadcast to a REST endpoint device.
 15. A non-transitory computerreadable storage medium comprising instructions that when executed causea processor to perform broadcasting a message to at least one server,the processor being further configured to perform: creating a message tobe broadcasted via user input; serializing the message to apredetermined format; transmitting the message to an applicationprogramming interface (API); scheduling a broadcast of the message basedon the user input; and transmitting the message to the at least oneserver responsive to the scheduled broadcast.
 16. The non-transitorycomputer readable storage medium of claim 15, wherein the message is acalendar message comprising at least one date to be broadcast and atleast time to be broadcast.
 17. The non-transitory computer readablestorage medium of claim 16, wherein the serialized message is aJavaScript object notation message (JSON) comprising a subject portionthat includes at least one date and time, and at least one body portionthat includes other message information.
 18. The non-transitory computerreadable storage medium of claim 16, wherein the processor is furtherconfigured to perform: receiving a hyper text transfer protocol (HTTP)response to confirm the at least one server's subscription to thebroadcast, the HTTP response being received responsive to the broadcastmessage.
 19. The non-transitory computer readable storage medium ofclaim 16, wherein the message further comprises a target uniformresource locator (URL) associated with the at least one server.
 20. Thenon-transitory computer readable storage medium of claim 16, wherein themessage is broadcast to a plurality of domains via a HTTP POST message.